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Docket No. 017.38448X00 (NC17179) 

SENDING A CHARGING IDENTIFICATION 
IN A MOBILE NETWORK 

BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates to mobile networks and, more particularly, the present 
invention relates to a technique for sending a charging identification in mobile networks. 

Description of the Related Art 

In general, packet switched wireless networks provide communications for mobile 
terminals with no physical connection required for network access. The General Packet 
Radio Service (GPRS) in the Global System for Mobile Communications (GSM) and the 
Universal Mobile Terrestrial System (UMTS) have both been developed to provide wireless 
communications networks with a packet switched side, as well as a circuit switched side. 

The specifications for UMTS networks with further improvements have been 
released by the 3rd Generation Partnership Program ( www.3qpp.org). Release 99 of the 
UMTS specifications provides that a network subscriber can have one or more packet data 
protocol (PDP) addresses. Each PDP address is described by one or more PDP contexts in 
the Mobile Terminal (MT), the Service GPRS Support Node (SGSN), and the Gateway 
GPRS Support Node (GGSN). The GGSN is a gateway to external networks. Each PDP 
context may have routing and mapping information for directing the transfer of data to and 
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from its associated PDP address and a traffic flow template (TFT) for filtering the transferred 
data. 

Each PDP context can be selectively and independently activated, modified, and 
deactivated. The activation state of a PDP context indicates whether data transfer is 
5 enabled for a corresponding PDP address and TFT. If all PDP contexts associated with the 
same PDP address are inactive or deactivated, all data transfer for that PDP address is 
disabled. All PDP contexts of a subscriber are associated with the same Mobility 
Management (MM) context for the International Mobile Subscriber Identity (IMS!) of that 
subscriber. Setting up a PDP context means setting up a communication channel. 

10 FIG. 1 is a process flow diagram that illustrates an example of the PDP context 

activation procedure. In step 100, the MT sends an Activate PDP Context Request to the 
SGSN. The Activate PDP Context Request message sent in step 100 includes a number of 
parameters. The parameters include a PDP address and an Access Point Name (APN). 
The PDP address is used to indicate whether a static PDP or dynamic PDP address is 

15 required. The APN is a logical name referring to the Gateway GPRS Support Node (GGSN) 
to be used. 

In step 102, the SGSN sends a Radio Access Bearer (RAB) setup message to the 
UMTS Terrestrial Radio Access Network (UTRAN) or the GERAN or other corresponding 
radio access networks . In step 104, the SGSN sends a Create PDP Context Request 
20 message to the affected GGSN. The GGSN decides whether to accept or reject the 

request. If it accepts the request, it modifies its PDP context table and returns a Create PDP 
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Context Response message in step 106. The SGSN then sends an Activate PDP Context 
Accept message to the Mobile Terminal in step 108. 

In spite of the numerous details provided in the aforementioned protocol, many 
features associated with mobile networks have not been dealt with. Specifically, charging 
5 information can be created by the SGSN, the GGSN and by the IP telephony network 

elements, e. g. the CSCF, and at present there is no solution in place to provide any means 
to associate the charging information created by the SGSN, the GGSN and the charging 
information created by the CSCF. This is needed in order to implement network functionality 
such as hot billing or merely to allow a network operator to implement joint billing for GPRS 
10 services and IP telephony services. 



SUMMARY OF THE INVENTION 
According to a first illustrative embodiment of the invention, when an Activate PDP 
Context Request message is forwarded to a Service GPRS Support Node (SGSN) by an 

15 MT, the SGSN creates a Create PDP Context Request message and forwards it to a 

Gateway GPRS Support Node (GGSN). In response to the Create PDP Context Request 
forwarded by the SGSN, the GGSN creates a Create PDP Context Response message. 
When a PDP context is created by the GGSN, the GGSN associates a Charging 
Identification parameter with the PDP context. Then, the Create PDP Context Response 

20 including the Charging Identification parameter is forwarded to the SGSN. In response to 
the PDP Context Response forwarded by the GGSN to the SGSN, the SGSN forwards an 
Activate PDP Context Accept message to the MT. According to the first embodiment of the 
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invention, both the Charging Identification parameter and possibly the GGSN address are 
provided to the MT in the Activate PDP Context Accept message. As described herein, the 
mobile station (MS) includes two parts: the terminal equipment (TE) and the mobile terminal 
(MT). The MS may also be referred to as user equipment (UE). The TE can, e.g., be a 
5 laptop which is then connected to the MT. The MT can be a mobile phone. 

Sending the GGSN address is not mandatory. Another alternative is that the CSCF 
adds the IP address of the MS to the charging records (CDRs) that it creates for a call. The 
SGSN and the GGSN already add the PDP address of the PDP context to the CDRs. By 
checking that the PDP address is the same as the IP address, it can be ensured that the 

10 PDP context has been used for the call in question. Since this requires that the charging 
identifications are the same, the CSCF adds the Charging Identification to the CDRs that it 
creates for the call in question. 

According to a second illustrative embodiment of the invention, the Charging 
Identification can be sent from the SGSN or the GGSN to the Call State Control Function 

15 (CSCF). When an Activate PDP Context Request message is forwarded to the SGSN, the 
SGSN creates a Create PDP Context Request message. The SGSN sends the Create 
PDP Context Request to the GGSN. In response to the Create PDP Context Request 
received from the SGSN, the GGSN creates a Create PDP Context Response. The GGSN 
associates the Charging Identification parameter with the PDP context. The Create PDP 

20 Context Response including the Charging Identification parameter is then forwarded to the 
SGSN. 



4 



Docket No. 017.38448X00 (NC17179) 



The Charging Identification parameter can be sent from either of the SGSN or the 
GGSN directly to the CSCF; and, such sending of the Charging Identification parameter can 
be performed either autonomously, e.g., at PDP context activation, or based on a request 
from the CSCF. 

5 In a specific embodiment, the CSCF sends the charging identification towards an 

endpoint of a communication, and sends security information together with said charging 
identification toward the endpoint. The CSCF is able to send an address of a GGSN 
together with the charging identification to the endpoint. If the GGSN address is not sent 
with the charging identification, the CSCF adds the IP address of the mobile station (UE) to 
10 theCDRs. 

The principles of the invention are applicable to other types of communication 
channels in addition to PDP contexts. 

Other aspects and advantages of the invention will become apparent from the 
following detailed description and accompanying drawings, illustrating by way of example 
1 5 the features of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The foregoing and a better understanding of the present invention will become 
apparent from the following detailed description of example embodiments and the claims 
20 when read in connection with the accompanying drawings, all forming a part of the 
disclosure of this invention. While the foregoing and following written and illustrated 
disclosure focuses on disclosing example embodiments of the invention, it should be clearly 
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understood that the same is by way of illustration and example only and the invention is not 
limited thereto. The spirit and scope of the present invention are limited only by the terms of 
the appended claims. 

Figure 1 is a generalized process flow diagram illustrating the PDP context activation 
5 procedure. 

Figure 2 is a generalized block diagram of the architecture of a packet switched 
wireless communication network in which the example embodiments of the invention can be 
practiced. 

Figure 3 is a generalized process flow diagram illustrating sending a charging 
10 identification in accordance with a first embodiment of the present invention. 

Figure 4 is a generalized process flow diagram illustrating sending a charging 
identification in accordance with an arrangement of a second embodiment of the present 
invention. 

Figure 5 is a generalized process flow diagram illustrating sending a charging 
15 identification in accordance with another arrangement of the second embodiment of the 
invention. 



DETAILED DESCRIPTION OF THE INVENTION 
Before beginning a detailed description of the subject invention, mention of the 
20 following is in order, when appropriate, like reference numerals and characters may be used 
to designate identical, corresponding, or similar components in differing drawing figures. 
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Furthermore, in the detailed description to follow, example sizes/models/values/ranges may 
be given, although the present invention is not limited thereto. 

An example of a network architecture supporting these specifications is the wireless 
communications network shown in the block diagram of FIG. 2. The various elements of the 
5 network and their functions are described in the General Packet Radio Service (GPRS) 
Service Description, Stage 2, 3GPP TS 23.060, published by the 3rd Generation 
Partnership Program ( www.3qpp.org) . The elements and their functions may be described 
in earlier or later versions of the 3GPP TS 23.060 specifications or maybe those of any other 
known packet switched wireless communications network. The description of network 

f. in 

Cj 10 elements and their functions are merely a non-limiting example of packet switched wireless 
\Jl communication networks. 

ry Several elements of the example network illustrated in FIG. 2 are particularly 

□ relevant to this invention. The Mobile Terminal (MT), commonly referred to as a cell phone 

: : y or a mobile phone, is only one possible part of User Equipment (UE). Typically, Terminal 

|H 15 Equipment (TE), used together with a Mobile Terminal (MT), constitutes User Equipment 
(UE), which is also referred to as a Mobile Station (MS). Any UE may be utilized in 
conjunction with this invention so that it operates or can be programmed to operate in the 
manner described below. The UMTS Terrestrial Radio Access Network (UTRAN) and the 
Base Station System (BSS) in GPRS manage and control the radio access between the 
20 core network and a number of MTs. There are also other possible radio access networks 
like GERAN. 
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The CSCF is a network element in an IP telephony network. The IP telephony 
network is sometimes referred to as "the application layer". The structure and function of the 
Call State Control Function (CSCF) can be divided into several logical components, which 
are currently internal to the CSCF. Every CSCF acting as a Serving CSCF has a Call 
Control Function (CCF) function. The CSCF includes an ICGW (Incoming call gateway). 
The ICGW acts as a first entry point. The ICGW performs routing of incoming calls. 
Incoming call service triggering (e.g. call screening /call forwarding unconditional) may need 
to reside for optimization purposes. The ICGW performs Query Address Handling (implies 
administrative dependency with other entities); and communicates with the Home 
Subscriber Server (HSS). 

The CCF (Call Control Function) performs call set-up/termination and state/event 
management; interacts with MRF in order to support multi-party and other services; reports 
call events for billing, auditing, intercept or other purposes; receives and process application 
level registration; performs query address handling (implies administrative dependency); 
and may provide service trigger mechanisms (service capabilities features) towards 
application & services network (VHE/OSA). The CCF may invoke location based services 
relevant to the serving network, and may check whether the requested outgoing 
communication is allowed given the current subscription. 

The CSCF includes a SPD (Serving Profile Database). The SPD interacts with HSS 
in the home domain to receive profile information for the R00 all-IP network user and may 
store them depending on the SLA with the home domain. The SPD notifies the home 
domain of initial user's access (which includes, e.g., CSCF signalling transport address, user 
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ID, etc.) The SPD may cache access related information (e.g. terminal IP address(es) 
where the user may be reached, etc.) 

The CSCF performs AH (Address Handling) function. The AH function includes 
analysis, translation, modification, if required, address portability, and mapping of alias 
5 addresses. The AH function may do temporary address handling for inter-network routing. 

The Serving GPRS Support Node (SGSN) is the node that serves the MT. At PDP 
context activation, the SGSN establishes a PDP context used for routing purposes. The 
Gateway GPRS Support Node (GGSN) is the node accessed by the external packet data 
network due to evaluation of the PDP address. It contains routing information for attached 
10 GPRS/UMTS users. The routing information is used to tunnel Protocol Data Units (PDUs) to 
the SGSN. The SGSN and GGSN functionalities may reside in different physical nodes or 
may be combined in the same physical node, for example, the Internet GPRS Support Node 
(IGSN). 

The IP-based mobile network architecture includes an application level and a 
15 transport level. The transport level protocols and mechanisms are usually optimized for the 
specific type of access whereas the application level is normally generic, that is independent 
of the type of access. 

In IP-based mobile networks, the UE sets up a call by signaling to the peer entity and 
exchanging messages of a call control protocol over an IP connection provided by the 
20 transport levels. In setting up a call in the application level, the underlying transport level 

has to set up the transport bearers over the radio interface and in the transport network. For 
an IP-based mobile network, setting up of transport bearers means allocating radio 
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resources and network resources. The call control signaling is transparently exchanged over 
an IP connection provided by the transport level. 

Embodiment 1 

5 FIG. 3 illustrates a process of sending a charging identification in accordance with a 

first embodiment of the present invention. In UMTS all-IP networks, when GPRS/UMTS is 
adopted as access/transport network for multimedia and voice over IP services, charging will 
be performed independently at the GPRS/UMTS layer and at the application layer (e.g., the 
CSCF). 

10 In the GPRS and UMTS networks, PDP contexts are created by the GGSN upon 

request from the SGSN (with a Create PDP Context Request message) that, in turn, 

receives the request from the MT (an Activate PDP Context Request message). 

As illustrated in FIG. 3, the technique in accordance with the present invention 

begins at the application level at step 300 in which a trigger is forwarded from the TE 
15 (Terminal Equipment) to the MT (Mobile Terminal). The trigger may be, e.g., a call set up 

indication including the requested logical channels and characteristics, sent from the TE to 

the MT to start PDP context activation. 

At step 302, an Activate PDP Context Request message is forwarded to the SGSN. 

In response thereto, in step 304, the SGSN creates a Create PDP Context Request 
20 message and forwards it to the GGSN. In response to the Create PDP Context Request 

forwarded by the SGSN, in step 306, the GGSN creates a Create PDP Context Response 

message. 



10 



Docket No. 017.38448X00 (NC17179) 



In step 308, when a PDP context is created by the GGSN, the GGSN associates a 
Charging Identification parameter with the PDP context in step 308. Then, in step 310, the 
Create PDP Context Response message including the Charging Identification parameter is 
forwarded to the SGSN. 
5 In turn, in response to the PDP Context Response forwarded by the GGSN to the 

SGSN, in step 312, the SGSN forwards an Activate PDP Context Accept message to the 
MT. According to the first embodiment of the invention, both the Charging Identification 
parameter and the GGSN Address are provided to the MT in the Activate PDP Context 
Accept message. 

10 The above noted procedures in steps 300-312 are repeated as many times as 

needed depending on the PDP contexts needed. 

Upon the completion of the last procedure in step 312, the UE forwards a call set up 
message, including requested logical channels and characteristics, to the CSCF (Call State 
Control Function) in step 314. The MT will, in turn, provide the Charging Identification and 

15 the GGSN Address to the CSCF within the call set up message. The CSCF, in turn, 

forwards the call set up message, including requested logical channels and characteristics, 
to the remote end point in step 316. The remote end point then forwards a response 
message, including accepted logical channels and characteristics, back to the CSCF in step 
318. The CSCF then forwards the response message, including accepted logical channels 

20 and characteristics, to the UE in step 320. The response message may be, e.g., the 

Connect message in H.323 or a SIP response message, but not necessarily limited to those. 
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The invention contemplates that the Charging Identification parameter can be made 
more secure by applying appropriate cryptographic algorithms to avoid a false Charging 
Identification being forwarded by a malicious MT to the CSCF instead of the legitimate 
value, or a malicious MT re-using a value of the Charging Identification. 
5 From the foregoing, it will be appreciated that in the first embodiment of the 

invention, the Charging Identification parameter is sent from the SGSN to the UE and from 
the UE to the CSCF. 



Embodiment 2 

10 FIG. 4 illustrates a process of sending a charging identification in accordance with an 

arrangement of a second embodiment of the present invention. In UMTS all-IP networks, 
when GPRS/UMTS is adopted as the access/transport network for multimedia and voice 
over IP services, charging will be performed independently at the GPRS/UMTS layer and at 
the application layer (e.g., the CSCF). 

15 In the GPRS and UMTS networks, PDP contexts are created by the GGSN upon 

request from the SGSN (i.e., a Create PDP Context Request message) that, in turn, 
receives the request from the MT (i.e., an Activate PDP Context Request). According to the 
second embodiment of the invention, the Charging Identification parameter is sent from the 
SGSN or the GGSN to the CSCF, Unlike the first embodiment, there is no need to send the 

20 Charging Identification parameter via the UE. 

As described previously, in the first embodiment of the invention, the MT intercepts 
data packets that are sent from the TE and adds the Charging Identification parameter to a 
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specific data packet ( the SIP message or the H.323 message for call set up). Interception 
of data packets may decrease the performance of the MT. 

In the second embodiment of the invention, the GPRS/UMTS and IPT network 
elements are able to co-ordinate charging information, e.g., in order to combine charging 
5 information collected for a PDP context by the SGSN and the GGSN and for a call by the 
CSCF. Like the first embodiment, the GGSN allocates a Charging Id parameter at PDP 
context activation. And like the first embodiment, the GGSN sends the Charging id 
parameter to the SGSN. But, unique to the second embodiment, the Charging Identification, 
possibly together with other information (e.g., IMSI, MSISDN, PDP address, UE port number 
10 from the TFT, Charging Characteristics etc.) can be sent from the SGSN or the GGSN to the 
CSCF. 

Sending the Charging Id parameter can be performed either autonomously or based 
on a request from the CSCF. The SGSN will send the Charging Identification, since the 
address of the CSCF has to be known if something will be sent to it. The SGSN has an 

15 interface with the HSS (HLR+UMS), which contains the address of the serving CSCF. 

There also can be an interface between the GGSN and the CSCF. This new 
interface could then be used to carry the Charging Id and possibly other charging related 
information. FIG. 4 illustrates an aspect of the second embodiment of the invention in which 
the SGSN sends the Charging-ld parameter to the CSCF. 

20 As illustrated in Figure 4, a process of sending a charging identification in 

accordance with the present invention begins at step 400 in which a trigger is forwarded 
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from the TE (Terminal Equipment) to the MT (Mobile Terminal). The trigger may be, e.g., a 
call set up message including the requested logical channels and characteristics. 

At step 402, an Activate PDP Context Request message is forwarded to the SGSN. 
In response thereto, in step 404, the SGSN creates a Create PDP Context Request 
5 message. 

In step 406, the SGSN sends the Create PDP Context Request to the GGSN. In 
response to the Create PDP Context Request received from the SGSN, in step 408, the 
GGSN creates a Create PDP Context Response. In step 410, the GGSN associates the 
Charging Identification parameter with the PDP context. In step 412, both the Create PDP 

10 Context Response and the Charging Identification are then returned to the SGSN in the 
Create PDP Context Response message. 

The Charging Id is included in the CDRs created by the GGSN and the SGSN. The 
CDRs are sent to the Charging Gateway Functionality (CGR) for further processing. From 
the Charging Gateway Functionality, the CDRs are sent to the Billing System. This is true 

15 for all the embodiments. In addition, it is important that the CSCF adds the Charging Id to 
the CDRs that it creates for the call in question. The CSCF sends CDRs either to the 
Charging Gateway Functionality (CGF) or to the Billing System. This way, when creating a 
bill for a subscriber, the PDP context(s) that were used for a specific call can be checked. 
The Charging Identification in all those CDRs is the same. 

20 If the Charging Characteristics change during an active PDP context, the SGSN 

includes the new Charging Characteristics of the PDP context in an Update PDP Context 
Request message, which the SGSN sends to the GGSN. 
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According to this arrangement of the second embodiment, the Charging Id 
parameter, possibly together with other information (e.g., IMSI, MSISDN, PDP address, UE 
port number from the TFT, Charging Characteristics etc.), is sent from the SGSN directly to 
the CSCF in step 414. This is done either autonomously (in a first case) or based on a 
5 request from the CSCF (in a second case). 

In the first case, at PDP context activation (and modification), the SGSN sends a 
message including the Charging Id and possibly other information (see above) to the CSCF. 
The message sent by the SGSN may be acknowledged by the CSCF. 

The SGSN must know the CSCF address. The CSCF address may be requested 
10 from the HSS or may be derived from the TFT which the UE specifies for the PDP context 
which is used for the communication with the CSCF. 

In the second case, at call set up, the CSCF requests information from the SGSN. 
The request is based, e.g., on IMSI or MSISDN. The SGSN sends the Charging Id and 
possibly other information (see above) to the CSCF. 
15 The CSCF must know the SGSN address. The SGSN address may be requested 

from the HSS. 

The CSCF, in turn, forwards the call set up message to the remote end point in step 
416. The remote end point then forwards a response message back to the CSCF in step 
418. The CSCF then forwards the response message to the UE in step 420. 
20 FIG. 5 illustrates another arrangement of the second embodiment of the invention in 

which the GGSN sends the Charging Identification directly to the CSCF. Referring to FIG. 5, 
a process of sending a charging identification in accordance with the present invention 
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begins at step 500 in which a trigger is forwarded from the TE to the MT (Mobile Terminal). 
The trigger may be, e.g., a call set up message including the requested logical channels and 
characteristics. 

At step 502, an Activate PDP Context Request message is forwarded to the SGSN. 
In response thereto, in step 504, the SGSN creates a Create PDP Context Request 
message. In step 506, the SGSN sends the Create PDP Context Request to the GGSN. 

In response to the Create PDP Context Request received from the SGSN, in step 
508, the GGSN creates a Create PDP Context Response. In step 510, the GGSN 
associates the Charging Identification parameter with the PDP context. In step 512, the 
Create PDP Context Response message including the Charging Identification is then 
returned to the SGSN. 

According to this aspect of the second embodiment, the Charging Id parameter, 
possibly together with other information (e.g., IMSI, MSISDN, PDP address, UE port number 
from the TFT, Charging Characteristics etc.), is sent from the GGSN directly to the CSCF in 
step 514. Step 514 is performed either autonomously (in a first case) or based on a request 
from the CSCF (in a second case). 

In the first case, at PDP context activation (and modification), the GGSN sends a 
message including the Charging Id and possibly other information (see above) to the CSCF. 
The message sent by the GGSN may be acknowledged by the CSCF. 

The GGSN needs to know the CSCF address. The CSCF address may be 
requested from the HSS or may be derived from the TFT which the UE specifies for the PDP 
context that is used for the communication with the CSCF. 
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In the second case, at call set up, the CSCF requests information from the GGSN. 
The request is based, e.g., on IMSI or MSISDN. The GGSN sends the Charging Id 
parameter and possibly other information to the CSCF. 

The CSCF forwards the call set up message to the remote end point in step 516. 
5 The remote end point then forwards a response message back to the CSCF in step 518. 
The CSCF then forwards the response message to the UE in step 520. 

The second embodiment allows the GPRS and IPT network elements to co-ordinate 
charging information, e.g., in order to combine charging information collected for a PDP 
3 context by the SGSN and the GGSN and for a call by the CSCF. Sending the Charging 

Hi 10 Identification from the SGSN or the GGSN to the CSCF requires an interface between the 
1-& application level network and the transport level network. 

m It is to be noted that in the description of the invention above, numerous details 

p known to those skilled in the art have been omitted for the sake of brevity. Such details are 

y i 

m readily available in numerous publications including the previously cited protocol. 

.X» 

q 15 Although the present invention has been described with reference to a number of 

illustrative embodiments, it should be understood that numerous other modifications and 
embodiments can be devised by those skilled the art which will fall within the spirit and 
scope of the principles of this invention. More particularly, reasonable variations and 
modifications are possible in the component parts and/or arrangements of the subject 
20 combination arrangement within the scope of the foregoing disclosure, the drawings, and 
the appended claims without departing from the spirit of the invention. In addition to 
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variations and modifications in the component parts and/or arrangements, alternative uses 
will also be apparent to those skilled the art. 
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WHAT IS CLAIMED IS: 

1 1 . A method for coordinating charging information in a communications network, 

2 the method comprising: 

3 establishing a communication channel; 

4 associating a charging identification with said communication channel; and 

5 sending said charging identification from a first network element in the transport 

6 layer to a second network element in the application layer. 



1 2. The method of claim 1, wherein said second network element adds said 

2 charging identification to charging information which said second network element 

3 collects. 



1 3. The method of claim 1, wherein said first network element sends an address 

2 of a network element together with said charging identification to said second network 

3 element. 



1 4. The method of claim 3, wherein said second network element adds said 

2 address of a network element to charging information which said second network 

3 element collects. 
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1 5. The method of claim 1 or 3, wherein said first network element sends security 

2 information together with said charging identification to said second network element. 

1 6. The method of claim 5, wherein said second network element verifies said 

2 charging identification against said security information. 

1 7. The method of claim 1, wherein said communication channel is a Packet Data 

2 Protocol (PDP) context. 

1 8. The method of claim 1, wherein said charging identification is a GGSN 

2 allocated Charging Id. 

1 9. The method of claim 1, wherein said first network element is a Mobile Station 

2 (MS). 

1 10. The method of claim 1, wherein said first network element is a Serving 

2 GPRS Support Node (SGSN). 
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1 11. The method of claim 1 , wherein said first network element is a Gateway 

2 GPRS Support Node (GGSN). 

1 12. The method of claim 1, wherein said second network element is a Call State 

2 Control Function (CSCF). 

1 13. The method of claim 9 or 12, wherein an SGSN sends said address of a 

2 network element to said first network element. 

1 14. The method of claim 9, 10, 11 or 12, wherein said address of a network 

2 element is an address of a GGSN. 

1 15. The method of claim 1 , wherein said transport layer is a GPRS/UMTS. 

1 16. The method of claim 1, wherein said transport layer is a Packet Switched 

2 Core Network domain. 
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1 17. The method of claim 1, wherein said application layer is a IP Multimedia Core 

2 Network domain. 

1 18. The method of claim 1, wherein said communication network is a packet 

2 switched wireless network. 

1 19. The method of claim 1, wherein 

2 sending said charging identification is performed autonomously. 

1 20. The method of claim 1, wherein 

2 sending said charging identification is performed based on a request from said 

3 second network element. 

1 21 . The method of claim 1 , wherein said second network element sends said 

2 charging identification towards an endpoint of a communication. 
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1 22. The method of claim 21, wherein said second network element sends security 

2 information together with said charging identification toward said endpoint of a 

3 communication. 



1 23. The method of claim 21, wherein said second network element sends an 

2 address of a network element together with said charging identification to said endpoint of a 

3 communication. 



1 24. The method of claim 9, wherein said second network element adds an address 

2 of said first network element to charging information which said second network element 

3 collects. 



1 25. An apparatus for coordinating charging information in a communications 

2 network, the apparatus comprising: 

3 a charging identification associated with a communications channel; and 

4 a first network element sending said charging identification in the transport layer to a 

5 second network element in the application layer. 
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1 26. The apparatus of claim 25, wherein said communication channel is a Packet 

2 Data Protocol (PDP) context. 

1 27. The apparatus of claim 25, wherein said charging identification is a GGSN 

2 allocated Charging Id. 

1 28. The apparatus of claim 25, wherein said first network element is a Mobile Station 

2 (MS). 

1 29. The apparatus of claim 25, wherein said first network element is a Serving GPRS 

2 Support Node (SGSN). 

1 30. The apparatus of claim 25, wherein said first network element is a Gateway 

2 GPRS Support Node (GGSN). 

1 31 . The apparatus of claim 25, wherein said second network element is a Call State 

2 Control Function (CSCF). 
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ABSTRACT OF THE DISCLOSURE 
In a first embodiment of the invention, when an Activate PDP Context Request 
message is forwarded to a Service GPRS Support Node (SGSN), the SGSN creates a 
Create PDP Context Request message and forwards it to a Gateway GPRS Support Node 
5 (GGSN). In response to the Create PDP Context Request forwarded by the SGSN, the 
GGSN creates a Create PDP Context Response message. When a PDP context is created 
by the GGSN, the GGSN associates a Charging Id parameter with the PDP context. Then, 
the Create PDP Context Response including the Charging Id parameter is forwarded to the 
SGSN. The Charging Id parameter is sent from the SGSN to the UE and from the UE to the 
10 CSCF. In a second embodiment of the invention, the Charging Id parameter is sent from 
the SGSN or the GGSN directly to the Call State Control Function (CSCF). Sending the 
Charging Id parameter can be performed either autonomously or based on a request from 
the CSCF. 
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